International Journal of Computer Science and Information Security (IJCSIS), 
Vol. 16, No. 4, April 2018 


A Ranking Model for Software Requirements 
Prioritization during Requirements 
Engineering: a case study 


Ishaya P. Gambo 
Department of Computer 
Science and Engineering, 
Faculty of Technology 
Obafemi Awolowo 
University 
Ile-Ife, Nigeria 
ipgamb@gmail.com 


Rhoda N. Ikono 
Department of Computer 
Science and Engineering, 
Faculty of Technology 
Obafemi Awolowo 
University 
Ile-Ife, Nigeria 
rhoda_u@yahoo.com 


Philip O. Achimugu 
Department of Computer 
Science, Lead City 
University, Ibadan, 
Nigeria 

check4philo@gmail.com 


Olaronke G. Iroju 
Department of Computer 
Science, Adeyemi College 
of Education, 

Ondo,Nigeria 
rojuolaronke@gmail.com 


Abstract- Software requirements prioritization is a 
recognized practice in requirements engineering (RE) 
that facilitates the management of stakeholders’ 
subjective views as specified in their requirements 
listing. Since RE process is naturally collaborative in 
nature, the intensiveness from both knowledge and 
human perspectives opens up the problem of decision 
making on requirements, which can be facilitated by 
requirements prioritization. However, due to the large 
volume of requirements elicited when considering an 
ultra-large-scale system, existing prioritization 
techniques proposed so far suffer some setbacks in 
terms of efficiency, effectiveness and scalability. This 
paper employed the use of a more efficient ranking 
algorithm for requirements prioritization based on the 
limitations of existing techniques. The major objective 
is to provide a well-defined ranking procedure through 
analysis, suitable for prioritizing software requirements. 
An empirical evaluation of the proposed technique was 
made using a typical scenario of the Pharmacy 
Information System at the Obafemi Awolowo 
University Teaching Hospital Complex (OAUTHC) as a 
case study. The results showed the computation of the 
positive ideal solution (PIS) and negative ideal solution 
(NIS), as well as the closeness coefficient (CC) for 4 
requirements across 3 stakeholders. The CC showed the 
final ranks of requirements, where R4 with 2.09 point is 
the most valued requirements, while R1 and R2 with 
CC of 1.37 and 1.05 were next in the order of priority 
respectively. The CC provides the medium through 
which problems of multiple criteria decision making 
can be handled, so as to determine the order of priority 
of the available alternatives. The paper conveyed 
encouraging evidence for the software engineering 
community that is capable of resolving redundant 
specified requirements, thereby providing the potential 
that will facilitate effective and efficient decision 
making in handling the differences amongst 
requirements that have been prioritized. Thus, 
prioritizing software requirements with the 
recommended ranking procedure during software 
development is crucial and vital in order to reduce 
development cost. 

Keywords: Software systems, requirements engineering, 
requirements prioritization, ranking algorithm. 

I. Introduction 

In engineering software systems during 
requirements engineering process, requirements 
prioritization is essential for the purpose of 


implementing an agreeably ultra-large scale system. 
For instance, in developing critical systems with 
large number of stakeholders’ requirements, 
prioritization can help in facilitating the choice of the 
final requirements listing as specified by the 
stakeholders [1]. Thus, prioritization of elicited 
requirements is essential in the development of 
software products that will meet the desired goals of 
stakeholders. The requirements in this context 
include useful information that will satisfy the need 
of the users or project stakeholders [2], and 
prioritizing them will help to prevent breaches in 
contracts such as budget over-shoot, exceeding 
delivery time and missing out important requirements 
during implementation [3]. We therefore see 
requirements prioritization as a process of managing 
the subjective views of stakeholders as specified in 
their requirements listing. This is with the aim of 
handling and negotiating the contradictory and 
conflicting expectations from each stakeholder 
among other reasons specified in Liaskos et al [4]. 

However, the selection and prioritization of 
requirements for the purpose of engendering a 
system of high quality is seen as a major challenge in 
software development [5]. It is obvious in literature 
that prioritization supports the recognition of all the 
foremost requirements as perceived by relevant 
stakeholders [6], and it is the activity required for the 
selection of appropriate requirements [7]. This is 
with a view of implementing the core sets of 
requirements with respect to cost, quality, available 
resources and delivery time [8, 9]. Hence, this paper 
further buttressed the importance of requirements 
prioritization and suggests that unmistakable ranking 
of requirements is an essential success factor for 
ensuring efficient requirements engineering process. 
In this case, the importance of every requirement 
should be based on each stakeholder’s subjective 
view, which makes it multidimensional since it is 
dependent on the stakeholders’ perspective [10]. The 
primary objective of ranking stakeholders’ 
requirements in a software development process is to 
aid the analysis of the to-be system by providing the 
order of their implementation plan amidst available 
alternatives [11, 12, 13, 14]. However, due to the 
large volume of data (referred to as stakeholders’ 
requirements), a number of prioritization techniques 
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proposed so far suffer some setbacks. The resultant 
effect of such setbacks makes it impossible for 
software developers to unveil interesting and 
actionable information about the expected 
requirements for the software project and product. 

In this paper, we propose a well suited ranking 
procedure given the basic flow of processes expected 
in the prioritization of software requirements, and the 
corresponding algorithm. The remaining part of this 
article has been structured as follows: The second 
section reveals the related works, the third section 
deals with the proposed method indicating the 
various tasks of the ranking procedures and 
emphasized on its suitability and relevance for 
software prioritization. The fourth section presents 
the experimental set-up also covering the empirical 
evaluation of proposed method on a case study; the 
fifth section presents and discussess the results; while 
the sixth section concludes the research and identify 
suggested future work. 

II. Related works 

In the software engineering literatures, several 
authors support the need for prioritizing software 
requirements in making the right choice from the 
different viewpoint aspects of stakeholders. For 
instance, the authors in [15, 16, 17, 18, 19] 
considered how requirements can be prioritized in a 
multi-team agile context, considering the change- 
driven nature of the agile methodology. Even in the 
goal oriented requirements engineering (GORE) 
methodology, prioritization is considered most 
important for the purpose of picking out the goals 
with respect to domain specific needs [20, 21, 22, 23]. 
However, providing a well-defined ranking 
procedure suitable for prioritizing software 
requirements across the various aspects and 
methodology is essential for implementation plan 
amidst available alternatives. 

Consequently, the advantages of prioritizing 
software requirements is beneficial to software 
development project and practises as established for 
decades in the literature. For example, Pitangueira et 
al [24] conducted a systematic review to investigate 
and analyze the various approaches proposed in 
literature to address software prioritization and 
selection problems. Their emphasis was based on 
Search-Based Software Engineering (SBSE), and 
their findings indicated the aspects addressed by 
most researchers, and the most prominent techniques 
used based on the defined problem. Additionally, 
Gambo et al. [1] considered the possibility of 
integrating Fuzzy Multi Criteria Decision Making 
(FMCDM) alongside similarity measures and target- 
based approaches to requirements prioritization using 
linguistic values of triangular fuzzy numbers. The 
emphasis in [1] was on how to avert subsequent 
system failure by making precise and accurate 
decision in developing large scale software systems. 
However, an algorithm that will rank and/order these 
sets of requirements is essential to the enhancement 
of the proposed techniques in [1]. 


Other examples of related works from literature 
include: (1) the work of Babar et al [5] on the 
analysis of various issues associated with existing 
prioritization techniques. These authors observed that 
existing prioritization techniques suffer a lot of 
setback because they can only handle software 
projects with very few requirements specifications. 
Consequently, this has rendered current techniques 
unsuitable for the prioritization of large scale sets of 
requirements during software development. (2) the 
work of Achimugu et al [25] provided another in- 
depth review that was based on the classification of 
existing prioritization techniques, and focused on 
their various setbacks and processes. The authors 
made some pertinent discoveries and 
recommendations on the grey areas for enhancement. 
(3) the work of Pergher and Rossi [26] provided the 
justification of evaluating prioritization tools by 
conducting a methodological mapping study. This 
was further supported by Dabbagh et al [27] with 
focus on executing two consecutive controlled 
experiments that aimed at evaluating current 
prioritization techniques. (4) the work of Rinkevics 
and Torkar [28] that focused on the empirical 
analysis of commutative voting and the 
corresponding outcome. The authors proposed the 
ECV methods for the analysis of results from the CV 
technique. Again, this technique suffers some setback 
in terms of analyzing, negotiating and prioritizing 
large number of requirements during development. 

In most cases, the common result with 
prioritizing software requirement is an ordering of 
prioritized lists of requirements that needs to be 
considered first during the software development 
process [29]. The justification for the acceptance of 
software systems by its stakeholders have been based 
on how well the requirements are captured, analyzed 
and prioritized [30, 31, 32]. The literature contained 
a lot of contribution that have been made in 
requirements prioritization research [33, 34]. This is 
evident in the renowned number of techniques that 
have been proposed and implemented at different 
times, and on different development projects. 
Common to these techniques is their ability to define 
requirements with greater value to business successes. 
Racheva et al [35] and Berander et al [36] provided 
different categorization of prioritization techniques. 

The first categorization by Racheva et al [35] 
includes two main classes: (1) techniques applicable 
to small-scale requirements, for example, round-the- 
group prioritization, multi-voting system, pair-wise 
analysis, weighted criteria analysis, and the quality 
function deployment techniques; and (2) techniques 
useful for large-scale requirements, for example, 
MoSCoW, binary priority list, planning game, case 
based rank and the Wiegers’s matrix techniques. 

The second categorization by Berander et al 
[36] also provided two main classifications. The first 
classification was based on techniques that support 
the assignment of values and/or weights by project 
stakeholders on each requirement. The essence of 
this classification is to describe the importance of 
each requirement comparatively. An example of this 
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includes the analytical process (AHP), planning 
game, cumulative voting, numerical assignment, and 
Wieger’s method. The second classification suggests 
the approaches supporting negotiation. In this case, 
the priorities of requirements are ascertained from 
the agreement established among the subjective 
evaluation given by each stakeholder. An example of 
this classification is the Win-Win model and multi 
criteria preference analysis requirement negotiation 
(MPARN) technique. 

However, all the techniques from each 
categorization given in [35] and [36] have their 
limitations. For example, with the Analytical 
Hierarchy Process (AHP) as a technique, an n x (n - 
1) / 2 comparison was proposed at each hierarchy 
level given n requirements. This has been evidently 
seen as a shortcoming of the AHP. This is because 
when the number of requirements increases, the 
number of comparisons will also increase with a 
magnitude of 0(n 2 ) [37, 38]. In addition, the AHP 
and CBRanks techniques have demonstrated high 
capabilities as reported in [5]. Both techniques are 
easy to use, and their accuracy level is very high. 
Still, their limitations are based on lack of support for 
scalability [39, 40, 41], and the inability to support 
rank reversals. This is obvious when considering a 
larger number of requirements for developing large 
scale system like the hospital systems. Detailed work 
that provided more insight on existing requirements 
prioritization and their corresponding shortcomings 
have been reported in [25] and other related works. 
Therefore, we proposed a more efficient ranking 
algorithm for requirements prioritization based on the 
limitations of existing techniques. 

III. Proposed method 

Fig. 1 described the procedures and 
corresponding processes adapted from Perini et al. 
[42] for the purpose of prioritizing software 


requirements. It consists of two phases which involve 
the manual and automated phases. The manual 
phases have to do with the specification and 
weighting of requirements while the automated 
process has to do with ranking of the weighted 
requirements and the display of the final ranked 
requirement. As shown in fig. 1, the ranking 
procedure indicating the basic flow of processes 
involved in prioritizing software requirements 
consists of some important tasks which must be 
observed in order to achieve reliable prioritization 
results. These tasks are enumerated below: 

1) Requirement Elicitation: This is the number one 
task in the process of requirements prioritization. It 
involves the elicitation, gathering and/or extraction 
of requirements. To elicit requirements, the elicitor, 
developer or engineer must articulate the description 
of problem source and how the proposed software is 
meant to solve the problem identified to the co-opted 
stakeholders. These stakeholders must acquire 
adequate understanding of the problem domain and 
proposed solution before elicitation commences. In 
cases where stakeholders come with their own 
requirements, adequate care must also be taken to 
analyze each requirement with respect to feasibility 
of implementation, relevant hardware support 
availability and compatibility, availability of skilled 
programmers, budget constraints, delivery time and 
the overall value of the proposed software to the 
organization or end-users. To initiate the elicitations 
process, the stakeholders are led to express their 
views in short sentences where each stakeholder 
quietly document requirements. Thereafter, 
stakeholders engage in a round-robin feedback to 
collate all the requirements so that a discussion 
section could be organized to arrive at consensus 
requirements and resolve ambiguities. The 
requirement elicitation process is given by Equation 
1 below: 




Where: 

• i and j are the specified requirements from 
the first to the last stakeholder, respectively. 

is the total number of elicited 

requirements from an origin node, “s” to a 
last node, “d”. 


a is an integer which is non-negative 

is the total number of stakeholders 

and their respective specified requirements. 
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Fig. 1. Model’s Information Flow (Adapted from Perini et al. [42]) 


2) Pair Sampling: This task is required in 
determining the relative importance of a requirement 
against the other. The relative importance is 


proposed system. Given some sets of requirements 
(ri, rj ^ R ), the process of pair sampling can be 
represented with the sets of equations enumerated 


determined based on pre-defmed criteria. Usually, below: 

the criteria are set based on the targeted output of the 
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r j-2 ’ r (t—lpj-i) ~~ ’ S ‘^‘ e ^ 
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® 

... , ... - ... ;s.t./jeR 
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? r (2.,a) = ^2 ? s -f 4/ e R 

(5) 


Where: 

• i and j are the consensus requirements from 
the first to the last 

• ® is the transitive operator that aid the 
comparison between one requirement and 
the other 

• r are given sets of requirements 

• R is the pool of consensus requirements 

3) Preference Elicitation: This is the act of 
obtaining results of the pair sampling processes from 
the stakeholders. More precisely, this task is 
concerned with the collection of all the weighted 
requirements based on set criteria (c). These weights 
are eventually used to compute of the final rank of 


the entire requirements. The preference elicitation 
process is executed with the following expressions: 

® : R x R —> {-l, 0, 1} where ® (n, rj) c = 
1 means that rj has been ranked above n, 

® (n, rj)c = -1 means that n has been 
ranked above r 7 , and 

® (n, rj)c = 0 indicates that no preference 
has been given between n and rj 

(We assume ® (n, rj) c = 0 and ® (n, 
rj)c = - ® (rj, ri) c for all n, rj ^ R). 

4) Ranking Learning: The weights of requirements 
obtained from (iii) serves as input during ranking 
learning. The idea here is to compute all the specific 
ranks of each requirement across all the stakeholders. 
The learning process relies on the prescribed weights 
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and ranking criteria to process ranking results. Given 
some sets of weights; W^W lV on requirements (n, 

rj ^ R); ranking R* can be executed using the 
equation 6: 

= 

E?=i W f ri f \V } rjZU W H rn,\V m rmR* (s ^ 

s.t. i & j; n &m > 1; (6) 

Where: 

• R * stands for ranked requirements 

• s and d are denoted for the start and end of 
the consensus requirements 

• W stands for the weights allotted to each 
requirement 

• r are given sets of requirements 

• i and j represents the relative requirements 

• n and m represents the end of relative 
requirements 

5) The Final Rank: This is the output of the entire 
process which reflects the value of each requirement 
as perceived by the stakeholders. Software 
requirement specifications deal with the 
representations of structural components and the 
relationships that tie them together. In order to avoid 
vague specification of requirements, we have 
suggested the application of composition operator 
) that will support pair wise comparison which 
has the capacity of pre-processing requirements. The 
synchronization of these representations can be easily 
achieved if all the components of the proposed 


software are well identified and consistently 
articulated. The preceding description of the 
proposed requirement prioritization technique forms 
part of the research contributions and will lead to 
unambiguous requirements specification. 

The inputs to the model consist of the following: 

(a) A set of finite requirements R = {n, , 

r n }. 

(b) The ranking criteria C= {c\, . . ., c m ). 

(c) The stakeholders’ preferences 
represented by the function ® (n, rj ) c 

During rank computations, the essence is to 
generate a priority list of all the requirements 
contained in R. This priority is represented by the 
function P: R —> R. The function P stands for the 
hierarchy of R determined by the preference weights 
allotted to the various requirements. The aim of any 
prioritization exercise is to reduce the level of 
discrepancies or disagreements between prioritized 
requirements in order to curb ranking error as well as 
ensure scalable prioritization process. Therefore, if n, 
rj, are given sets of requirements, it is important to 
ensure the transitive closure ® (n, rj) > 0. This will 
ensure non-zero weights on any requirement. The 
proposed algorithm has the capacity of ordering 
requirements based on weighted scores. 

In fig. 2, we demonstrated that the actual input 
to the ranking process is a finite set of elicited 
requirements that are about to be ranked while the 
ultimate output of the entire process consists of sets 
of displayed ranked requirements based on pre¬ 
defined criteria. The criteria in this context outlined 
the steps considered suitable in the ranking process 
as defined in the ranking algorithm. 



Fig. 2. Ranking-based flow of processes in prioritizing software requirements 


In the algorithm, the focus here is to assign 
membership functions against each requirement 
based on the allotted weights in order to construct a 
decision matrix. For instance, assuming we have sets 
of requirements R elicited from a particular software 
development project, R.(i = 1,2,...,m) which is been 

evaluated with respect to the number n of selected 
criteria c\(/ = l,2,...,«) that constitute each of those 

requirements; then, weights can be determined by 
relevant stakeholders to track the following: (a) the 
criteria that are to be utilized in ranking the 


requirements and (b) construction of the decision 
matrix using the linguistic variables expressed in 
Table 1. 


TABLE I: Linguistic variables 


S/N 

Variables 

Meaning 

1 

VL 

Very Low 

2 

L 

Low 

3 

M 

Medium 

4 

H 

High 

5 

VH 

Very High 
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The weighted criteria w stand for the After obtaining the weighted requirements w ; the 

comparative rank of the chosen criteria; while, proposed algorithm works as follows: 

decision matrix represents the overall ranking of each 

C 

requirement Ri in line with the prescribed criteria J . 

Step 1 : Construction of the decision matrix X ; The weights are used to construct decision matrix of the 
form shown below: 




Cl 

c 2 • 

•• c n 


R, 

X 11 

X 12 

••• X ln 

D = 

r 2 

x 2 , 

X 22 

••• X 2 n 


R m 

_ X ml 

X m 2 

••• X mn 

W~- 

= [w, 

w 

2 

w n ] 


After constructing decision matrix, there is need to normalize the matrix by using Equation 8. 


i 

R v =Ev = = l ’~ m ( 8 ) 

j =1 

Step 2: Aggregation of normalized decision weights: The aggregated weights for the normalized entries 
are computed by obtaining the square root of each of the normalized weight using Equation 9. 

W J= (9) 

Step 3: Computation of the aggregated fuzzy decision matrix in its linguistic form using Equation 10. 

Ry = Y J x 2 i ji = \,...n\j = \,..m (10) 

j =i 


Step 4: Computation of the global weights: The ith values in Step 3 are multiplied by each values of the 
aggregated decision matrix in Step 2 using Equation 11 to acquire the global weights of each criterion. 


Wj = 


= 


, X "'2,/ X 


,xY J x 2 ij,i = l,..n;j = 1,... 

j =i 


m 


( 11 ) 


Step 5: Computation of the Positive Ideal Solution (PIS) and Negative Ideal Solution (NIS): The 
solutions from the global decision matrix values in Step 4 are used to compute the PIS and NIS. To compute the 
PIS, Equation 12 is utilized. 




( 12 ) 


Where, Vj* = the maximum values of the requirement entries in the aggregated decision matrix. NIS is 
computed with Equation 13. 


A = 


v i ,v 2 ,-**,v w 


(13) 


Where, v' = the minimum values of the requirement entries in the aggregated decision matrix. 

Step 6: Computation of the separating distances: This is achieved by finding the variance amidst the 
highest and lowest values contained in the aggregated decision matrix as depicted in Equation 14. 
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S, = - A~v )) (14) 


Where / = l,2,---,m 

Step 7: The results in step 6 represent the 
confidence rating of each requirement with respect to 
the relevant stakeholders. Therefore, the requirement 
with the highest confidence rating (CR) value is 
considered as the prime requirement. 

In dealing with decision making challenges 
during software elicitation process, it is necessary to 
consider the number of requirements specified by 
stakeholders (or the number of criteria that makes up 
each requirement) in order to find the Euclidean 
distances amongst positively ideal requirements. 
Assuming a particular software engineer have 
acquired two major requirements for a certain 
software development project, say (Ri, R 2 ); then it 
becomes lighter to determine the PIS criteria which 
consist of all highly ranked criteria that constitute a 
requirement. Conversely, the NIS which consists of 
criteria that are least ranked is also detected. 
However, if two requirements Ri and R 2 possess a 
shorter distance to both PIS and NIS; it becomes 
quite imperative to clearly define the rationale for 
choosing one over the other or choosing both as the 
case may be. This algorithm deals with the concept 
of considering alternatives, known as compromise 
solution, that possesses the nearest distance to the 
PIS and the farthest distance from the NIS. 

IV. Experimental set-up 

To illustrate the concept of these techniques, 
the Pharmacy Information System at the Obafemi 
Awolowo University Teaching Hospital Complex 
(OAUTHC) was considered in this case. Consider the 
following scenario: “The Pharmacy Department at 
OAUTHC would like to develop new software to 
replace the existing one so that a better solution for 
the pharmacy operation is achieved, and each 
pharmacy sub-unit’s functions and activities are 
captured. The new system should facilitate the 
administration of both outpatient and inpatient 
medication supplies to the wards, and also provides 
inventory support to manage stock movement from 
any given location across the three tiers of healthcare 
delivery system in Nigeria”. 

The system must be flexible enough to enable 
Pharmacists and other experts gain access into the 
system and administer the appropriate healthcare 
services. Bearing in mind that, OAUTHC and other 
hospitals deal with complex and large amount of data; 
there would be a need to build a scalable system that 
will be dynamic and interoperable. Thus, the need to 
provide an appropriate measure of ranking 
requirements in a manner to avoid delay in 
implementation, reduce cost of development, and 
ensure quality assurance and control. The system 
should also be able to assist in patient care by the 
monitoring of drug interactions, drug allergies and 
other possible medication-related complications, in 
addition to capturing relevant medical information. 


The essence of capturing this medical information of 
patients could be aimed at indexing into a well- 
structured database that is void of redundancy or 
replications. Basically, the software system can be 
developed to enable Pharmacist to manage 
medication orders, ensure that preparations, 
dispensing, and verification are all easily completed 
and monitored. 

From the above scenario, the software 
engineers and other relevant stakeholders are trying 
to gather information in order to ensure that, the 
proposed system works as expected. Nine 
stakeholders are involved in this case. Based on the 
elicited information, the architectural design 

decisions are made. Due to several reasons, 

architectural decision-making is a difficult task 
because: (i) requirements are usually captured with a 
lot of ambiguous insinuations (ii) functional and non¬ 
functional requirements are difficult to explicitly 
specify (iii) concrete architectural decisions have to 
be made based on vague requirements in some cases 
(iv) stakeholders involved have different perspectives, 
views or concerns. 

Possessing a mastery of sound elicitation 
technique and being able to clearly describe 

problems leads to concise specification of 

requirements. This is the key for developing a 
formidable architecture for software systems. To get 
started, software engineers and stakeholders must be 
able to choose views, sort them, prioritize and 
document them which translate to the following 
sequence of activities: 

a. The utilization of an elicitation technique 
must lead to unambiguous requirements 
specification. 

b. The architectural design must conform to 
the elicited requirements. 

c. The quality attributes of the proposed 
system are selected from the non-functional 
requirements class. 

d. The mapping between architectural design 
decisions and requirement specifications 
must be consistent. 

During or after requirements specification, it is 
important to collapse them into categories as 
described in the hierarchical representation of the 
specified requirements shown in fig. 3. This will 
enhance clarity in the evaluation process; since these 
requirements are about to be prioritized. When 
prioritization is to commence, requirements are 
compared pair-wisely where relevant stakeholders 
are required to determine the relative importance of 
each requirement based on the comparison scale. The 
requirements undergoing pair wise comparison are 
performance, reusability, flexibility and 
maintainability; denoted as Ri, R2, R3 and R4 
respectively. 
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Level 1 : Goal Level 2 : Specifications Level 3 : Criteria 


Level 4 : Attributes 


Requirements 


Quality of service (Rn) 


Through™ it 

Latency 

CPU utilization 


Performance 

(RO 


Scalability (Ri 2 ) 


Security (R13) 


Data communication 
(R14) 


Data redundancy (R15) 


■c 


Flexibility 

m 


Installations ease (R22) 


R= 


User friendliness (R23) 


U Compatibility (R31) 



j— Code 


changes (R32) H= 


I File changes (R33) 



Distributed data processing 
Large data storage 

Data integrity issues 
Intrusions detection 
Defining users’ limit 

Update 

Delete 

Edit 

File/Data transfer 
Record linkage 


Executable set up file 
Simple installation guide 
Concise user interface 
Informative 
Self-explanatory 
Operating systems changes 
Hardware changes 

Editable code 
Well labeled code 

Modifications 
Interoperable 
Data structures hierarchy 

SRS document 
SD document 

Performance sustainability 


Hardware requirements 

Product familiarization 


Fig. 3. Categorization of Stakeholder’s requirements 


In the context of the Pharmacy information 
system from literature, performance has to do with 
the overall deliveries supported by a system. 
However, the attributes that constitute this 
requirement include quality of service (system 
availability); scalability (large amount of data 
processing at runtime) and Security (protection of 
patient data against malicious or unauthorized users), 
data communication (basic database updates across 
distributed database applications) and data 
redundancy (ability of a distributed database system 
to detect or avoid data replications by linking records 
to appropriate entities). 


The requirement tagged flexibility on the other 
hand has to do with the level of portability of the 
system. That is, the ability of the system to be 
installed and used across any operating system 
platform. Precisely, the attributes under this category 
are installation ease (ability for the system to be 
easily installed on independent platforms); user 
friendliness (a system with concise and unambiguous 
features or functions). Interfaces are expected to be 
designed with clear links or Webpages and 
compatibility; that is, the ability of the system to 
adapt to sudden changes in technological or 
infrastructural advancement. 
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Reusability measures the extent at which a 
system can be long lived; that is, the degree at which 
a system can evolve or adapt to operating system 
changes or modifications, as well as data, algorithm 
and file changes. This is crucial because, a system 
that is not reusable will not have any future value. If 
a system ends up not having any future value, it 
creates an impression that money has been wasted in 
the project. Moreover, organisations in recent times 
are beginning to appreciate systems that possess the 
ability to adapt to future changes with little or no 
administrative interventions. 

Finally, the maintenance requirement is 
responsible for prolonging or sustaining the life span 
of the developed software systems. This involves the 
provision of the software requirement and design 
documents as well as the application codes, a 
periodic maintenance plan and a user training session 
to enable users get themselves acquainted with the 
software system and installation manual which will 
help guide users to a successful installation of the 
software. This could also help them perform simple 
maintenance exercises. 

V. Results and discussion 

Table 2 indicates how the subjective priorities 
given to each requirement by the stakeholders were 
captured. To achieve that, the linguistic valuations 
were introduced. In this case, Ranking Scales (RS) 
were used as variables. The RS are assertions that use 
expressions in English language to represent values 
that stands for the degree of acceptability of a 
particular variable or parameter. One advantage of 
the linguistic variables is the ability to determine the 
level of acceptability amongst specified requirements 
by each stakeholder. Therefore, using the RS, 
stakeholders were able to provide preference weights 
for the elicited requirements based on their perceived 
importance. 

Next to the priority list indicated by the RS is 
Tables 3 and 4 showing the ranking with normalised 
and aggregate weights derived from equation 8 and 9 
respectively. These normalised decision weights 
determine the performance of ranking algorithm. 
Tables 5 and 6 showed the Fuzzy and Global 
decision matrices derived from equation 10 and 11 
respectively. The fuzzy logic concept was employed 
in [1] as a way of overcoming complexities in 
decision making. Consequently, equation 12 was 
used to compute the positive ideal solution (PIS) and 
negative ideal solution (NIS), as well as the closeness 
coefficient (CC). 

The two ideal solutions (PIS and NIS) were 
computed for 4 requirements across 3 stakeholders as 
shown in Tables 7 and 8 respectively. PIS and NIS 
was introduced to provide intuitive and 
computationally feasible approach to identify the CC. 
Hence, the CC showing the final ranks of 
requirements are depicted in Table 9. The CC 


provides the medium through which problems of 
multiple criteria decision making can be handled, so 
as to determine the order of priority of available 
alternatives. Experimentally, the CC showed that R4 
with 2.09 point is the most valued requirements. Next 
to R4 in the order of priority is R1 and R2 
respectively with CC of 1.37 and 1.05 respectively. 
Thus, we are optimistic that this ranking algorithm 
can cater for large dataset (i.e. large number of 
requirements). As such, prioritizing software 
requirements with the suggested ranking algorithm 
during software development can reduce 
development cost, and aid smooth release 
management of software products timely. 

Therefore, the results in Tables 2 to 9 represent 
the performance of the proposed technique. These 
results emphasized more on scalability and ranking 
evolving requirements. The advantages of the 
ranking algorithm are as follows: 

(a) Scalability: The algorithm can be applied to 
requirements of ultra-large scale software 
development projects since the weights of 
requirements can be computed across all their 
respective criteria at runtime. 

(b) Evolvability (Rank reversal): The algorithm also 
has the capacity of accurately calculating 
weights across even or odd numbers of criteria 
that constitute each requirement. The functions 
for computing PIS and NIS have the capacity of 
computing relative weights between odd or even 
requirements. 

VI. Conclusion and future work 

In this paper, we proposed a more efficient 
ranking algorithm that is capable of resolving 
redundant specified requirements. The ranking 
algorithm proposed, demonstrated the potential of 
catering for large number of requirements as datasets. 
Secondly, it has the potential of facilitating effective 
and efficient decision making that can handle the 
differences amongst requirements that have been 
prioritized. Therefore, it is believed that this 
approach can help software engineers to prioritize 
requirements capable of forecasting the expected 
behaviour of software under development. The 
implication of the final ranked requirements would 
be that those that emerged top in the ranked list will 
be implemented first while others can be 
implemented subsequently in the software release 
planning process. 

The next phase of this research can be tailored 
towards the minimization of discrepancies between 
ranked requirements. Secondly, the automation of the 
computations proposed in this paper and the display 
of ranked results will be required. Finally, it will be 
so interesting to validate this proposed technique 
with a real life software development project and 
applicable datasets as well as implementation of the 
prototype. 
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TABLE II: Linguistic variables 


Ri 

Rn 

RJ2 

Rl3 

Rl4 

Rl3 

r 2 

R:i 

R .22 

R23 

R 3 

R3! 

Rj2 

r 4 

R41 

R 42 

R43 

r^ 4 

Si 

VH 

VH 

VH 

VH 

VH 

Si 

H 

H 

H 

Si 

H 

H 

Si 

VH 

VH 

VH 

VH 

$2 

VH 

VH 

VH 

VH 

VH 

s 2 

VH 

V r H 

VH 

s 2 

VH 

VH 

s 2 

VH 

VH 

VH 

VH 

S 3 

H 

H 

H 

H 

H 

S 3 

VH 

VH 

VH 

s 3 

VH 

VH 

S 3 

M 

M 

M 

M 

S 4 

H 

H 

H 

H 

H 

s 4 

M 

M 

M 

S 4 

VH 

VH 

s 4 

VH 

VH 

VH 

VH 

s 3 

VH 

VH 

VH 

VH 

VH 

s 3 

H 

H 

H 

S 3 

M 

M 

S 3 

H 

H 

H 

H 

s 6 

H 

H 

H 

H 

H 

S6 

VH 

VH 

VH 

Ss 

M 

M 

Ss 

H 

H 

H 

H 

s 7 

VH 

VH 

VH 

VH 

VH 

S 7 

VH 

VH 

VH 

S 7 

M 

M 

s 7 

H 

H 

H 

H 

Ss 

H 

H 

H 

H 

H 

Ss 

M 

M 

M 

Ss 

H 

H 

Ss 

H 

H 

H 

H 

s 9 

VH 

VH 

VH 

VH 

VH 

S 9 

H 

H 

H 

s 9 

M 

M 

S 9 

VH 

VH 

VH 

VH 


TABLE III: Normalized weights 



TABLE IV: Aggregate weights 


Ri 

Rh 

R 12 

R 13 

Rl4 

Ru 


R 21 

R 21 

R^ 

Rj 

Ro! 

Rsi 

R4 

R 41 

R 42 

R 43 

R 44 

Si 

0.316 

0.316 

0.316 

0.316 

0.316 

Si 

0.245 

0.245 

0.245 

Si 

0.245 

0.245 

Si 

0.316 

0.316 

0.316 

0.316 

$2 

0.316 

0.316 

0.316 

0.316 

0.316 

S : 

0.316 

0.316 

0.316 

Si 

0.316 

0.316 

Si 

0.316 

0.316 

0.316 

0:316 

S 3 " 

0.245 

0.245 

0.245 

0.245 

0.245 

S 3 

0.316 

0.316 

0.316 

S 3 

0 316 

0.316 

S 3 

0.141 

0.141 

0.141 

0.141 

s 4 

0.245 

0.245 

0.245 

0.245 

0.245 

s 4 

0.141 

0.141 

0.141 

S 4 

0.316 

0.316 

s 4 

0.316 

0.316 

0.316 

0.316 

Sf 

0.316 

0.316 

0.316 

0.316 

0.316 

Ss 

0.245 

0.245 

0.245 

Sf 

0.141 

0.141 

S; 

0.245 

0.245 

0.245 

0.245 

S fi 

0.245 

0.245 

0.245 

0.245 

0.245 

S fi 

0.316 

0.316 

0.316 

s ; 

0.141 

0.141 

s fi 

' 0 .245 

0.245 

0.245 

0,245 

s- 

0.316 

0.316 

0.316 

0.316 

0.316 

S 7 

0.316 

0.316 

0.316 

s- 

0.141 

0.141 

s- 

0.245 

0.245 

0.245 

0.245 

_jh_ 

0.245 

0.245 

0.245 

0.245 

0.245 

Se 

0.141 

0.141 

0.141 

s & 

0.245 

0.245 

s 8 

0.245 

0.245 

0.245 

0.245 

Ss 

0.316 

0.316 

0.316 

0.316 

0.316 

s 5 

0.245 

0.245 

0.245 

S* 

0.141 

0.141 

Ss 

0.316 

0.316 

0.316 

0.316 
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TABLE V: Fuzzy decision matrix 


Ri 




Ri 




Rj 




Rj 




Si 

0.80 

1.25 

1.25 

Si 

0.27 

0.48 

0.75 

Si 

0.18 

0.32 

0.50 

Si 

0.64 

1.00 

1.00 

Sj 

0.80 

1.25 

1.25 

S 2 

0.48 

0.75 

0.75 

Sj 

0.32 

0.50 

0.50 

S 2 

0.64 

1.00 

1.00 

Si 

0.45 

0.80 

1.25 

S3 

0.48 

0.75 

0.75 

S3 

0.32 

0.50 

0.50 

S3 

0.16 

0.36 

0.64 

s 4 

0.45 

0.80 

1.25 

s 4 

0.12 

0.27 

0.48 

s 4 

0.32 

0.50 

0.50 

s 4 

0.64 

1.00 

1.00 

s< 

0.80 

1.25 

1.25 

s 5 

0.27 

0.48 

0.75 

s 5 

0.08 

0.18 

0.32 

s 5 

0.36 

0.64 

1.00 

s 5 

0.45 

0.80 

1.25 

S e 

0.48 

0.75 

0.75 

S 6 

0.08 

0.18 

0.32 

s* 

0.36 

0.64 

1.00 

S T 

0.80 

1.25 

1.25 

s- 

0.48 

0.75 

0.75 


0.08 

0.18 

0.32 

s- 

0.36 

0.64 

1.00 

s* 

0.45 

0.80 

1.25 

s* 

0.12 

0.27 

0.48 

s* 

0.18 

0.32 

0.50 

s* 

0.36 

0.64 

1.00 


0.80 

1.25 

1.25 

s® 

0.27 

0.48 

0.75 

s 9 

0.08 

0.18 

0.32 

s 5 

0.64 

1.00 

1.00 


TABLE VI: Global fuzzy decision matrix 


Ri 




Rj 




Ri 




R4 




Si 

1.00 

1.57 

1.57 

Si 

0.26 

0.47 

0.73 

Si 

0.13 

0.22 

0.35 

Si 

0.72 

1.12 

1.12 

s 2 

1.00 

1.57 

1.57 

Si 

0.47 

0.73 

0.73 

Si 

0.25 

0.40 

0.40 

Si 

0.72 

1.12 

1.12 

S3 

0.50 

0.89 

1.38 

S3 

0.47 

0.73 

0.73 

S3 

0.25 

0.40 

0.40 

S3 

0.12 

0.27 

0.48 

S4 

0.50 

0.89 

1.38 

S4 

0.15 

0.26 

0.47 

s 4 

0.25 

0.40 

0.40 

S4 

0.72 

1.12 

1.12 

s 5 

1.00 

1.57 

1.57 

s 5 

0.26 

0.47 

0.73 

Si 

0.04 

0.10 

0.17 

Si 

0.36 

0.63 

0.99 

s 5 

0.50 

0.89 

1.38 

Sf 

0.47 

0.73 

0.73 

Sj 

0.04 

0.10 

0.17 

s 5 

0.36 

0.63 

0.99 

s 7 

1.00 

1.57 

1.57 

s 7 

0.47 

0.73 

0.73 

S- 

0.04 

0.10 

0.17 

s- 

0.36 

0.63 

0.99 

s& 

0.50 

0.89 

1.38 

s 8 

0.15 

0.26 

0.47 

s 8 

0.13 

0.22 

0.35 

s £ 

0.36 

0.63 

0.99 

s 9 

1.00 

1.57 

1.57 

s 5 

0.26 

0.47 

0.73 

s 9 

0.04 

0.10 

0.17 

s 9 

0.72 

1.12 

1.12 
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TABLE VII: Positive ideal solution 






d + 

Ri 

1.00 

1.57 

1.57 

4.14 

r 2 

0.47 

0.73 

0.73 

1.93 

r 3 

0.25 

0.40 

0.40 

1.05 

R* 

0.72 

1.12 

1.12 

2.96 


TABLE VIII: Negative ideal solution 






d~ 

Ri 

0.50 

0.89 

1.38 

2.77 

r 2 

0.15 

0.26 

0.47 

0.88 

r 3 

0.04 

0.10 

0.17 

0.31 

Rt 

0.12 

0.27 

0.48 

0.87 


TABLE IX: Closeness coefficient 



d + 

d~ 

cc 

Ranking 

Ri 

4.14 

2.77 

1.37 

2 

r 2 

1.93 

0.88 

1.05 

3 

r 3 

1.05 

0.31 

0.74 

4 

R* 

2.96 

0.87 

2.09 
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